Adds Builder and VM Manager interfaces + implementation for UVM#2597
Adds Builder and VM Manager interfaces + implementation for UVM#2597rawahars wants to merge 2 commits intomicrosoft:mainfrom
Conversation
rawahars
force-pushed
the
feat/vm-package
branch
from
dd20499 to
207c612
Compare
Refactor the UVM code to clearly separate responsibilities across the VM layers (builder vs. vmmanager) and document the intended architecture. This reorganizes the former `internal/vm/hcs` package into focused builder and manager packages and updates the core interfaces/types. Key changes: - Introduce `internal/vm/builder` as the concrete `Builder` implementation for constructing HCS compute system documents. - Add `internal/vm/vmmanager` package for host-side UVM lifecycle and resource management; move HCS-backed managers here. - Replace the old `UVMBuilder` with a `Builder` interface and manager sub-interfaces for memory/processor/numa/device/boot/storage QoS. - Consolidate shared VM types and errors into `internal/vm/builder_types.go` (guest OS, memory backing, processor config, device IDs). - Add the `internal/vm/README.md` describing the 3-layer VM model and typical usage flow. - Move HCS-specific implementations into their new packages; delete obsolete `internal/vm/hcs` files and rename movers (boot/memory/network/etc.). - Normalize builder APIs to be configuration setters (no errors where Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
rawahars
force-pushed
the
feat/vm-package
branch
from
207c612 to
00b1f90
Compare
| // ReadOnly indicates whether the scsi disk is read only or not. | ||
| ReadOnly bool | ||
| // ExtensibleVirtualDiskType is the disk type of the extensible virtual disk. | ||
| ExtensibleVirtualDiskType string |
There was a problem hiding this comment.
This seems to only make sense when the type is EVD. Can we just have it be a sub type anyways?
| return uvm | ||
| } | ||
|
|
||
| func (uvm *utilityVM) AddSCSIDisk(ctx context.Context, disk vm.SCSIDisk) error { |
There was a problem hiding this comment.
Is there a reason we dont just use hcsschema.Attachment here for the caller? Like what is the need of having the SCSIDisk type in the middle what do we gain? Its just yet more translations
There was a problem hiding this comment.
Originally, we had planned on making the calls to each of these methods generic. That way any other backends can act as VMM. But given that we are coupling it to specifically HCS, we can make this change.
| LifetimeManager() LifetimeManager | ||
|
|
||
| // NetworkManager returns an interface for managing network adapters for the Utility VM. | ||
| NetworkManager() NetworkManager |
There was a problem hiding this comment.
I thought we said we werent going to do these and just have the static asserts so the caller can think of a VM as a NetworkManager great. But didnt need to indirect through this?
| return uvm | ||
| } | ||
|
|
||
| func (uvm *utilityVM) AddVPMemDevice(ctx context.Context, id uint32, path string, readOnly bool, imageFormat string) error { |
There was a problem hiding this comment.
Same here, to avoid more layers. Let the caller pass into the "syscall layer" the VirtualPMemDevice right? Like why have more translations
There was a problem hiding this comment.
Think about it this way. If you add VPMemDeviceMode::SomeNewMode do you want to have to update this function? Or make an overload? I don't... I just want the caller that reads it from some spec to set that flag and the rest of the layers just enact it.
2 participants
This pull request introduces a major refactor and formalization of the Utility VM (UVM) builder and management interfaces. It separates the responsibilities for VM configuration, host-side management, and guest-side actions into clear, testable layers. The changes include a new, well-documented builder interface, VM manager interface, concrete builder and VM manager implementations, along with comprehensive unit tests for the builder's functionality.
The most important changes are:
Architectural Refactor and Documentation
README.mdto theinternal/vmpackage, clearly explaining the separation of concerns between the Builder, VM Manager, and Guest Manager layers, and documenting the responsibilities and flow for each layer.Builder Interface and Implementation
UVMBuilderinterface with a new, comprehensiveBuilderinterface ininternal/vm/builder.go, providing modular access to memory, processor, NUMA, device, boot, and storage QoS configuration managers.Builderinterface ininternal/vm/builder/builder.gofor creating and configuringhcsschema.ComputeSystemdocuments.VM Manager Interface and Implementation
Testing
These changes establish a foundation for future VM configuration and management features.